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Abstract 



The present invention is directed towards a translation software that provides remote access to an 
application program that is executing on a host machine in its native operating system environment. The 
translation software monitors messages that are relayed from the application program to an application 
interface that is provided via the native operating system. Upon recognizing a message that affects a 
graphical user interface of the native operating system, the translation software converts the message into a 
protocol that is recognized by a remote graphical user interface. By monitoring and converting messages in 
this fashion, the translation software allows the application program to be displayed remotely. 
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@ Ein Verfahren und System zur dynamischen Obersetzung zwischen verschiedenen grafischen 
Benutzeroberflachen-Systemen 

@ Die vorliegende Erfindung betrifft ein Obersetzungs ver- 
fahren, das einen computerfernen Zugriff zu einem Anwen- 

dungsprogramm, das auf einer Hauptmaschine in ihrer 

ursprunglichen Betriebssystem-Umgebung ausgefuhit wird, 

schafft. Das Obersetzungsverfahren uberwacht Nachrichten, 

die von dem Anwendungsprogramm an eine Anwendungs- 

schnittstelle, die durch das ursprungliche Betriebssystem 

geschaffen wird, gerichtot werden. Auf das Erkennen einer 

Nachricht hin. die eine grafische Benutzeroberflache des 

ursprunglichen Betriebssystems betrifft, konvertiert das 

Obersetzungsverfahren die Nachricht in ein Protokoll, das 

von einer computerfernen, grafischen Benutzeroberflache 

erkannt wtrd. Durch Oberwachen und Konvertieren von 

Nachrichten auf diese Weise, ermoglicht es das Oberset- 
■ zungsprogramm, daS das Anwendungsprogramm computer- 
f fern dargestellt wird. 
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Beschreibung 

Technisches Gebiet 

Die vorliegende Erfindung betrifft eine Laufzeituber- 
setzung zwischen verschiedenen grafischen Benutzer- 
oberflachen Systemen und umfaBt insbesondere ein 
Verfahren und ein System, die es erlauben, Anwendun- 
gen, die fiir lokale Anzeigesysteme geschrieben wurden, 
fur computerf erne Anzeigemoglichkeiten eines anderen 
grafischen Benutzeroberflachen-Systems zu verwen- 
den. 

Hintergrund der Erfindung 

Derzeitig gibt es ungefahr 50 Millionen Computeran- 
wender. die eine grafische Benutzeroberflache venven- 
den, die als "WINDOWS" von der "MICROSOFT Cor- 
poration bekannt ist Derzeitig entwickelt sich sehr 
schnell "MICROSOFT'S WINDOWS/NT* als ein bevor- 
zugtes Betriebssystem. Als Konsequenz werden eine 
groBe Anzahl von Anwendungsprogrammen so ge- 
schrieben, daB sie mit "WINDOWS/NT kompatibel 
sind. "WINDOWS/NT' stellt eine einzelne grafische Be- 
nutzeroberflache zur Verfugung, an die sich all diese 
Anwendungsprogramme halten miissen. AuBerdem 
stellt ein Client/Server- Windowsystem, das als "X" be- 
kannt ist, und anf anglich am Massachusetts's Institute of 
Technology entwickelt wurde, ein Protokoll (X-Proto- 
koll) zur Verfugung, das es erlaubt, Anwendungspro- 
gramme computerfern auf einer oder mehreren grafi- 
schen Benutzeroberflachen (beispielsweise Motif, 
Open- Look) darzustellen. Unglucklicherweise sind die 
Anwendungsprogramme, die fur das ^WINDOWS/ 
NT'-Betriebssystem entwickelt worden sind, nicht mit 
dem X-Protokoll kompatibel Als Konsequenz haben 
Verwender des X-Client/Server-Windowsystems kei- 
nen bequemen Zugriff auf diese Anwendungsprogram- 
me. Dies ist unglucklich, weil viele der Anwendungspro- 
gramme, die fur das 'WINDOWS/NT*- Betriebssystem 
entwickelt worden sind, was die Kosten und die Merk- 
male betrifft, den fiir das X-Client/Server- Windowsy- 
stem entwickelten uberlegen sind. 

Zusammenf assung der Erfindung 

Die vorliegende Erfindung betrifft Obersetzungsver- 
fahren, die einen computerfernen Zugriff zu einem An- 
wendungsprogramm schaffen. Insbesondere stellt das 
Obersetzungsverfahren einen computerfernen Zugriff 
auf ein Anwendungsprogramm, das auf einem Haupt- 
rechner in seiner urspriinglichen Betriebssystemumge- 
bung ausgefiihrt wird, zur Verfugung. Das Oberset- 
zungsverfahren uberwacht Nachrichten, die von dem 
Anwendungsprogramm an eine Anwendungsschnitt- 
stelle gerichtet werden, die durch das urspriingliche Be- 
triebssystem zur Verfugung gestellt wird. Auf das Er- 
kennen einer Nachricht, die eine grafische Benutzer- 
oberflache des ursprunglichen Betriebssystems betrifft, 
hin, konvertiert das Obersetzungsverfahren die Nach- 
richt in ein Protokoll, das durch eine computerferne 
grafische Benutzeroberflache erkannt wird. Das Ober- 
setzungsverfahren uberwacht und konvertiert auch Be- 
fehle auf der Treiberebene. Durch Oberwachen und 
Konvertieren von Nachrichten auf diese Weise, erlaubt 
das Obersetzungsverfahren, daB das Anwendungspro- 
gramm computerfern dargestellt wird 
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Diese und weitere Vorteile der Erfindung ergeben 
sich aus der taillierten Beschreibung bevorzugter Aus- 
fuhrungsformen der Erfindung unter Bezugnahme auf 
die Zeichnungen. Es zeigen: 
5 Fig. 1 eine bevorzugte Ausfiihrungsform der vorlie- 
genden Erfindung, 

Fig. 2 einen Vergleich der Systemdesignmerkmale fiir 
ein Client/Server- Windowsystem und ein Betriebssy- 
stem, 

10 Fig- 3 ein FluBdiagramm der Verfahrensschritte der 
bevorzugten Ausfuhrungsform der vorliegenden Erfin- 
dung, 

Fig. 4 ein FluBdiagramm der Verfahrensschritte eines 
Anwendungsprogramms (Stand der Technik), 
15 Fig. 5 ein FluBdiagramm der Verfahrensschritte fur 
die Wechselwirkung zwischen dem Anwendungspro- 
gramm und einem ursprunglichen Betriebssystem 
(Stand der Technik), 

Fig. 6 ein FluBdiagramm der Verfahrensschritte fur 
20 ein Beispiel gemaB einer bevorzugten Ausfuhrungsform 
der vorliegenden Erfindung. 

Detaillierte Beschreibung der Erfindung 

25 Die vorliegende Erfindung betrifft ein Obersetzungs- 
verfahren, daB es erlaubt, ein fiir ein bestimmtes grafi- 
sches Benutzeroberflachensystem (GUI) geschriebenes 
Programm auf einem anderen grafischen Benutzerober- 
flachensystem mit der Laufzeit darzustellen. Das GUI, 

30 auf dem das Anwendungsprogramm dargestellt wird, ist 
als Ziel-GUI bezeichnet Falls das Ziel-GUI in der Lage 
ist, iiber ein Netzwerk computerfern darzustellen, er- 
laubt es das Obersetzungsverfahren, daB das Anwen- 
dungsprogramm computerfern dargestellt wird, und mit 

35 ibm computerfern interagiert wird, wahrend es inner- 
halb seines urspriinglichen (nicht-compterfernen) GUI 
ausgefiihrt wird. 

In einer bevorzugten Ausfuhrungsform sorgt die vor- 
liegende Erfindung fiir eine Obersetzung von Windows 

40 und *WINDOW$/NT* in das X- Windowsystem und er- 
moglicht somit eine computerferne Darstellung von An- 
wendungen. die fur "MICROSOFT WINDOWS" und 
'WINDOWS/NT' entwickelt wurden, auf X-Terminals 
und X-Servera. Insbesondere erlaubt die bevorzugte 

45 Ausfiihrungsform, daB jede derartige Anwendung als 
ein voUstandig kompatibles X-Clicnt-Programm zu 
computerfernen X-Servern erscheint Der Term 
"X-Client" betrifft ein Anwendungsprogramm, daB das 
vorher beschriebene X-ProtokoU verwendet Der Aus- 

50 druck "X-Terminal" betrifft irgendeine Anzeigekompo- 
nente (beispielsweise ein alleinstehendes Terminal oder 
ein Arbeitsplatz), der eine Anzeigekomponente eines 
X-Client/Server-Windowsystems ist Der Ausdruck 
•^-Server" betrifft das Verfahren, das die Anzeige- 

55 Hardware (beispielsweise eine Bildschirmanzeige, eine 
Tastatur oder eine Maus) steuert und ist verantwortlich 
fiir die Durchfiihrung der Zeichnung und der Bildaufbe- 
reitung der Bildschirmanzeige. Ein attraktives Merkmal 
eines X-Client-Programms ist es, daB es auf irgendei- 

60 nem X-Terminal dargestellt und/oder mit ihm inter- 
agiert werden kann (beispielsweise iiber eine Maus, eine 
Tastatur, eta), vorausgesetzt, daB eine geeignete Kom- 
munikationsverbindung (typischerweise, allerdings kei- 
ne Einschrankung darstellend, das unten beschriebene 

65 TCP/IP-ProtokoIl) vorhanden ist, das die Maschine, auf 
der der X-Client lauft, und das X-Terminal verbindet 

In dem X-Client/Server-Windowsystem kommuni- 
ziert ein X-Client mit der zugrundeliegenden Hardware 
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(beispielsweise Bildschirm, Maus, Tastatur, etc.) uber 
den X-Server. Ein getrennter X-Client, als Windowma- 
nager bekannt, koordiniert mit dem X-Server die Ver- 
waltung der Darstellung. Insbesondere verfolgt der 
Windowmanager die Zustande aller X-Windows. Der 
Ausdruck "X- Window" betrifft irgendeinen Abschnitt 
einer Anzeige eines X-Terminals, das seine eigenen Da- 
ten (beispielsweise ein Dokument oder eine Nachricht) 
enthalt. Ein wesentlicher Vorteil des X-Client/Server- 
Windowsystems ist es, da6 es einen X-Clienten nicht auf 
die Verwendung eines bestimmten Windowmanagers 
beschrankt Statt dessen kann ein Benutzer den Win- 
dowmanager auswahlen, von dem er glaubt, daB er das 
attraktivste Aussehen und Empfinden bietet 

Fig. 1 stellt eine bevorzugte Ausfuhrungsform der 
vorliegenden Erfindung dar. Ein Hauptrechner 1 10 fiihrt 
Anwendungsprogramme. beispielsweise "MICROSOFT 
EXCEL" 120 und "WORD FOR WINDOWS" 130 unter 
dem "WINDOWS/NT'-Betriebssystem 140 aus. Das 
^WINDOWS/NT" -Betriebssystem sowie die Anwen- 
dungsprogramme 120, 130 sind in einem Hauptspeicher 
des Hauptrechners enthalten. Insbesondere fiihrt eine in 
dem Hauptrechner 1 10 enthaltene CPU die Anwendun- 
gen sowohl des nVINDOWS/NT'-Betriebssystems 140 
als auch der Anwendungsprogramme 120, 130 aus. Das 
'WINDOWS/NT" -Betriebssystem schafft eine Anwen- 
dungsprogrammschnittstelle (APIX die diesem Anwen- 
dungsprogramm 120. 130 erlaubt, mit dem Betriebssy- 
stem 140 zu kommunizieren. Zusatzlich liefert das 
'WINDOWS/NT* Betriebssystem auch eine grafische 
Standardbenutzeroberflache (GUI), die das Aussehen 
und die Empfindung fur alle unter 'WINDOWS/NT" 
laufenden Anwendungen definiert Diese grafische 
Standardbenutzeroberflache ist so ausgelegt, daB sie 
Befehle von dem Anwendungsprogramm empfangL 
Kurz gesagt, verwenden die Anwendungsprogramme 
120, 130 die Anwendungsschnittstelle, urn vom Betriebs- 
system die Durchfuhrung einer VieLfalt von Aufgaben 
anzufordern. Beispielsweise umfassen reprasentative 
Aufgaben das Offnen und SchiieBen von Dateien sowie 
die Durchfuhrung verschiedener Einstellungen der gra- 
fischen Benutzeroberflache. AUerdings ermoglicht das 
"WINDOWS/NT" -Betriebssystem keine computerfer- 
ne Wechselwirkung mit Anwendungen. In seiner bevor- 
zugten Ausfuhrungsform uberwindet die vorliegende 
Erfindung diese Beschrankung von 'WINDOWS/NT*, 
indem es erlaubt, Anwendungsprogramme 120. 130 auf 
dem Hauptrechner auszufiihren. wahrend sie computer- 
fern auf einem X-Terminal 150 dargestellt werden. Auf 
diese Weise erlaubt die vorliegende Erfindung den Be- 
nutzern des X-Client/Server-Windowsystems. einen Zu- 
griff auf Anwendungen, die fur das "WINDOWS/ 
NT*-Betriebssystem entwickelt wurden. AuBerdem 
stellt. da die bevorzugte Ausfuhrungsform der vorlie- 
genden Erfindung es ermoglicht, die Anwendungspro- 
gramme 120, 130 in ihren ursprunglichen Betriebssy- 
stemumgebungen. (beispielsweise dem 'WINDOWS/ 
NT'-Beiriebssystem 140) auszufuhren. die vorliegende 
Erfindung einen derartigen Zugriff in einer sehr effizien- 
ten Weise zur Verfugung. 

Wie dargestellt. ist der Hauptcomputer 110 mit den 
X-Terminals 150 uber eine Netzwerkverbindung, wie 
beispielsweise dem in Ethernet verwendeten TCP/IP- 
ProtokoU, verbunden. Kurz gesagt, besteht dieses Pro- 
tokoll aus einer Reihe von Schichten. Insbesond re sind 
die funf unterstcn Schichten in aufsteigender Reihenfol- 
ge das Kabel. das Ethernet, das Internet-Protokoll (IP- 
Schicht). das TransportsteuerprotokoU (TCP-Schicht) 




22 185 Al 

4 

und das X-ProtokolL Diese Netzverbindung ist konzep- 
tionell durchdas Bezugszeichen 160 dargestellt 

Wie oben beschrieben verwendet das X-Client/Ser- 
ver-Windowsystem zwei Komponenten: einen X-Ser- 
5 ver 170 und einen Windowmanager 180. Der Win- 
dowmanager 180 verwahet die X-Windows, indem er 
verfolgt, wieviele X-Windows derzeitig dargesteUt wer- 
den, wo die X-Windows derzeitig dargestellt werden 
eta Da die vorliegende Erfindung die 'WINDOWS/NT* 

10 -Anwendung in einen voUstandig kompatiblen X-Client 
kohvertiert, kann ein Benutzer einen bestimmten Win- 
dowmanager 180 (beispielsweise Motif, Open-Look, 
Tom's Windowmanager) zur Verwendung mit der vor- 
liegenden Erfindung wahlen. Kurz gesagt empfangt der 

15 Windowmanager 180 Befehle. die die Darstellung auf 
den X-Terminals 150 betreffen. Da der Windowmana- 
ger 180 in dem X-Terminal selbst oder auf dem Netz- 
werk enthalten sein kann, kann der Windowmanager 
Befehle uber die Netzwerkverbindung 160 oder direkt 

20 von dem X-Terminal 150 empfangen. 

Fig. 2 vergleicht den Systemdesignaufbau fQr ein 
Client/Server-Windowsystem und ein Betriebssystem. 
Insbesondere vergleicht Fig. 2 den Systemdesignaufbau 
des X-Client/Server-Windowsystems und des 'WIN- 

25 DOWS/NT'-Betriebssystems. Eine Kenntnis dieser 
Strukturen ist bei der Diskussion der in den Fig. 3— 6 
beschriebenen Verfahrensschritte hilfreich. 

In "WINDOWS/NT* sind Programme (beispielsweise 
Anwendungsprogramme) iiber Geratetreiber 210 mit 

30 einer Standardschnittstelle zur Hardware 205 (beispiels- 
weise einer Anzeigeeinrichtung, einer Tastatur, einer 
Maus etc.) versehen. Die verschiedenen Komponenten 
215 des 'WINDOWS-NT"-Betriebssystems sind uber 
den Geratetreiber gelegt. Eine derartige Komponente 

35 ist die Grafiktreiberschnittstelle 220 (GDI), Die GDI 
erlaubt, daB Anwendungsprogramme grafische Infor- 
mationen ohne Bezugnahme auf die zugrundeliegende 
Hardware beschreiben. Die Anwendungsprogramm- 
schnittstelle 225 (API) existiert uber der ^WINDOWS/ 

40 NT'-Komponentenschicht . Die API umfaBt die Kon- 
zepte von Fenstern (Windows), Ikonen, Positionsanzei- 
ger und andere Mittel. "WINDOWS/NT* ist ein anreiz- 
gesteuertes, auf einer Nachricht basierendes System. 
Verschiedene Programme kommunizieren miteinander 

45 und mit dem 'WINDOWS/NT" durch Weitergabe von 
Nachrichten uber die API. In bezug auf grafisch darge- 
stellte Information verwendet die API Konstruktionen 
auf hoher Ebene, wie beispielsweise Fenster (Windows) 
Oder Ikonen. Im Gegensatz hierzu verwendet der Bild- 

50 schirmanzeige-Geratetreiber Darstellungen grafischer 
Daten (beispielsweise Bitmap- Daten) auf niedriger Ebe- 
ne. Ein Zweck der Bildschirmanzeige-Geratetreiber ist 
es, diese Bitmap-Daten zur Anzeigeeinrichtung zu iiber- 
tragen. Beispielsweise werden, wenn der Benutzer ein 

55 Fenster bewegt oder seine GroBe verandert. eine groSe 
Anzahl von BitBlts (Blockubertragungen vori Bitmap- 
Daten) durch den Anzeigeeinrichtungstreiber ausge- 
fiihrt 

Das X- Server/Client- Windowsys tern ist etwa ahnlich 
60 wie das "WINDOWS/NT'-Betriebssystem strukturiert 
Ein X-Server 230 stellt eine Standardschnittstelle zur 
zugrundeliegenden Hardware 235 zur Verfugung. Eine 
Bibliothek, Xlib 240, stellt eine Programmiererschnitt- 
steile (auf einer niedrigen Ebene) fur X zur Verfugung. 
65 Wenn der X-Client lokal lauf t, gibt der X-Client Befehle 
aus der Xlib-Bibliothek 240 aus. urn durch den X-Server 
230 auf die lokale Hardware 235 zuzugreifen. In ahnli- 
cher Weise gibt der X-Client. wenn er computerfern 
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lauft, Kommandos aus der Xlib-Bibliothek 240 aus, um 
auf die computerferne Hardware zuzugreifen. In diesem 
Fall werden Netzwerkdatenpakete, die Elemente des 
X-ProtokoUs darstellen, zum X-Server230, der die com- 
puterferne Hardware 235 bedient, geschickt Wie 'WIN- 
DOWS/NT* ist X ein anreizgesteuertes System und ein 
X-Client kann von dem X-Server 230 anfordern, dafl er 
X-Ereignisse von Interesse (wie beispielsweise. wenn 
die Maus in ein Fenster eintritt oder es verlaBt, der 
Benutzer etwas in einem Fenster anklickt, usw.) ab- 
schickt Wie oben erwahnt, ermoglicht ein spezielles 
X-Client-Programm, der Windowmanager 245, dem Be- 
nutzer, die dargestellten Windows zu verwalten, Menus 
zu def inieren usw. Neben der Xlib-Schnittstelle auf rela- 
tiv niedriger Ebene liefert ein X-Toolkit 250 (eine 
X-Werkzeugausrustung) eine Programmiererschnitt- 
stelle auf hoherer Ebene. Es gibt viele derartige Tool- 
kits, die kommerziell erhaltlich sind (beispielsweise die 
"XT"-, "ANDREW"- und "MOTIF"-Toolkits). Jedes To- 
olkit wird mit einer Sammlung von Produkten Widgets 
255. die eine niitzliche Sammlung von X-Objekten (bei- 
spielsweise einen rollbaren Text Wndow Widget) sind. 
Nachdem ein Vergleich der Strukturen des X-Client- 
Windowsystems und des "WINDOWS/NnT-Betriebssy- 
stems gegeben worden sind, werden nun die Verfah- 
rensschritte einer bevorzugten Ausfuhrungsform der 
vorliegenden Erfindung beschrieben. 

Fig. 3 stellt die ProzeBschritte einer bevorzugten 
Ausfuhrungsform der vorliegenden Erfindung dar. Ins- 
besondere gibt Fig, 3 einen Uberblick iiber die Verfah- 
rensschritte, die von dem Obersetzungsverfahren 
durchgefiihrt werden, um ein in seiner ursprunglichen 
Umgebung ablaufendes Anwendungsprogramm in ei- 
nen vollstandig kompatiblen Client eines nicht-ur- 
sprunglichen Windowsystems zu ubersetzen. Zuerst 
wird ein Anwendungsprogramm in seiner ursprungli- 
chen Umgebung (Schritt 305) ausgefiihrt Beispielsweise 
ist in einer bevorzugten Ausfuhrungsform diese ur- 
sprQngliche Umgebung das 'WINDOWS/NT'-Be- 
triebssystem. Wenn das Anwendungsprogramm in sei- 
ner ursprunglichen Umgebung ausgefiihrt wird, iiber- 
wacht das Obersetzungsverfahren die Systemaufrufe, 
die die Anwendung an die ursprungliche Umgebung 
iiber die Anwendungsprogrammschnlttstelle (Schritt 
310) der urspriinglichen Umgebung richtet Beispiels- 
weise iiberwacht in einer bevorzugten Ausfiihrungs- 
form das Obersetzungsverfahren die Befehle, die von 
dem Anwendungsprogramm an die durch "WINDOWS/ 
NT" zur Verfiigung gestellte Anwendungsprogramm- 
schnittstelle gerichtet werden. 

Fiir jeden iiberwachten Systemaufruf bewertet das 
Obersetzungsverfahren, ob der durch den API-Aufruf 
dargestellte Befehl das Windowmanagement betrifft 
Ein Befehi "betrifft das Windowmanagement", wenn die 
Ergebnisse des Befehls die Positionierung des Anwen- 
dungsprogramm- Fensters verandert (beispielsweise be- 
wegt, die GroBe verandert, das Anwendungsprogramm- 
Fenster in einen Stapelspeicher ablegt). Somit wirkt 
Schritt 315 als eine Abfangeinrichtung auf hoher Ebene 
zwischen dem Anwenderprogramm und dem urspriing- 
lichen Betriebssystcm. 

Wenn der API-Befehl das Windowmanagement be- 
trifft, suspendiert das Obersetzungsverfahren vorzugs- 
weise die Fahigkeit des ursprunglichen Geratetreibers 
(beispielsweise des Maustreibers, des Tastaturtreibers, 
des Bildschirmtreibers), den Befehl zu verarbeiten 
(Schritt 315, JA-Pfad und Schritt 320) aus. In einigen 
Fallen ist das Suspendieren der Fahigkeit des urspriing- 
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lichen Geratetreibers, den Befehl zu verarbeiten, vor- 
teilhaft, da es die Response-Zeit des Systems stark ver- 
groBert Durch das Anhalten des urspriinglichen Bild- 
schirmtreibers wahrend der Bewegung eines Fensters, 
5 zeichn t der urspriingliche Geratetreiber beispielsweise 
das Bild des Fenst rs nicht kontinuierlich nach, wenn 
der Benutzer das Fenster iiber den Bildschirm zieht Als 
Ergebnis schickt der Bildschirmtreiber nicht kontinuier- 
lich die BitBIts (Blocke von Bitmap-Daten), die das Bild 

10 des Fensters darsteUen, an die Bildschirmhardware. 
Konsequenterweise und insbesonders in Systemen, in 
denen eine lokale Darstellung der Ausfiihrung der An- 
wendung in ihrer urspriinglichen Umgebung nicht er- 
wunscht ist, wird die Systemperformance aufgrund der 

15 Reduktion einer. uimotigen Dateniibertragung stark 
verbessert. Nach Anhalten des urspriinglichen Gerate- 
treibers konvertiert das Obersetzungsverfahren den Be- 
fehl in ein Format, das durch das Ziel-GUI (Schritt 325) 
erkennbar ist In einer bevorzugten Ausfiihrungsform 

20 halt sich dieses Ziel-GUI an ein Protokoll, das als das 
X-ProtokoU bekannt ist Als Konsequenz konvertiert 
das Obersetzungsverfahren den API-Befehl in einen Be- 
fehl des X-ProtokoUs (beispielsweise einen Befehl aus 
der Xlib-Bibliothek). Wenn der Befehl konvertiert wor- 

25 den ist, gibt das Obersetzungsverfahren den Befehl an 
das Ziel-GUI-System weiter (Schritt 330). In einer be- 
vorzugten Ausfiihrungsform wird dieses Kommando 
beispielsweise an einen Windowmanager weitergege- 
ben. Der Windowmanager fuhrt dann diesen Befehl 

30 iiber den X-Server aus. Als optionalen Schritt kann das 
Obersetzungsverfahren den Befehl auch an das ur- 
sprungliche GUI-System weitergeben, so daB das Win- 
dowmanagement auf einer lokalen urspriinglichen An- 
zeigeeinrichtung ausgefuhrt wird (Schritt 335). Ob der 

35 optionale Schritt durchgefiihrt wird oder nicht, gibt das 
Obersetzungsverfahren den urspriinglichen Geratetrei- 
ber aus seinem angehaltenen Zustand frei (Schritt 335). 

Wieder Bezug nehmend auf Schritt 315 gibt das 
Obersetzungsverfahren, wenn der uberwachte Befehl 

40 das Windowmanagement nicht betrifft, den Befehl an 
das urspriingliche Betriebssystem des Anwendungspro- 
gramms weiter (Schritt 315. NEIN-PFAD, und Schritt 
340). Nachfolgend fangt das Obersetzungsverfahren je- 
den Systemaufruf auf der Geratetreiberebene ab und 

45 bestimmt, wann der Systemaufruf den mtemen Zustand 
des Anwendungsprogramm-Fensters beeinfluBt (Schritt 
340 und 345). Somit arbeiten die Schritte 340 und 345 als 
eine Abfangeinrichtung auf niedriger Ebene zwischen 
dem Anwendungsprogramm und dem urspriinglichen 

50 Betriebssystem. Fiir den Fall, in dem der Systemaufruf 
den intemen Zustand des Anwendungsprogramm-Fen- 
sters nicht beeinfluBt, ermSglicht das Obersetzungsver- 
fahren, daB das Anwendungsprogramm auf herkommli- 
che Weise ausgefiihrt wird, (Schritt 345, NEIN-PFAD, 

55 und Schritt 305). Wenn der Systemaufruf den intemen 
Zustand des Anwendungsprogramms-Fensters beein- 
fluBt, konvertiert das Obersetzungsverfahren anderer- 
seits den Systemaufruf in einen Ziel-GUI-Aufruf nach- 
dem der ursprungliche Geratetreiber angehalten wor- 

60 den ist (Schritt 345, JA-PFAD, Schritte 320 und 325). 
Nach dem Obersetzen des Systemaufrufs gibt das Ober- 
setzungsverfahren den iibersetzten Aufruf an das Ziel- 
GUI-System weiter (Schritt 330). Das Obersetzungsver- 
fahren gibt dann optional den Befehl an den urspriingli- 

65 Chen GUI-Gcratetreiber weiter (Schritt 335). Wiederum 
wird dieser optionale Schritt nur durchgefuhrt, wenn 
eine lokale Anzeige der Ausfiihrung des Anwendungs- 
programms in seiner urspriinglichen Umgebung er- 
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wunscht ist Durch Wiederholen der Verfahrensschritte 
305 bis 345 ermoglicht die vorliegende Erfindung, daB 
das Anwendungsprogramm in seiner ursprungiichen 
Umgebung ausgefiihrt wird, wahrend es gleichzeitig er- 
laubt, daB mit der Anwendung computerfern auf einem 
computerfernen Terminal oder einem Arbeitsplatz in- 
teragiert wird. Nachdem die Verfahrensschritte einer 
bevorzugten Ausfiihrungsform der vorliegenden Erfin- 
dung beschrieben worden sind, wird nun die bevorzugte 
Ausfiihrungsform mittels eines Beispiels erklart 

Fig, 4 stellt die Verfahrensschritte eines Anwen- 
dungsprogramms dar. Dieses Programm ist eatwickelt, 
urn in Verbindung mit einem Betriebssystem ein Fenster 
zu erzeugen, das den Text "Hallo" darstellL Die Durch- 
fiihrung des Programms beginnt durch Registrieren ei- 
ner Windowklasse (Fensterklasse) mit ihrem erwunsch- 
ten ursprungiichen Betriebssystem (Schritt 405). Diese 
Windowklasse beschreibt eine Reihe von globalen At- 
tributen fiir eine Klasse von Fenstern (Windows) (bei- 
spielsweise eine Ikone fur das Fenster, die erscheint, 
wenn das Fenster minimiert wird, die Hintergrundfarbe 
fur das Fenster etc). Wenn eine Klasse von Fenstern 
(Windows) in dem Betriebssystem eingetragen worden 
ist, erzeugt das Programm ein Fenster fur die Kiasse 
unter Verwendung eines Create Window-API-Aufrufs 
(Schritt 410). Der Create- Window- API- Auf ruf erzeugt 
das erwunschte Fenster intern in dem Speicher des Co- 
mutersystems. Um das Window auf der Bildschirman- 
zeigeeinrichtung darzustellen, gibt das Programm einen 
ShowWindo w-API- Aufruf ab (Schritt 420). Eine Verfah- 
rensscWeife, kollektiv durch die Blocke 430, 435, 440 und 
450 dargesteilt, fordert dann das Zeichnen des Texts 
"Hallo" auf der Bildschirmanzeigeeinrichtung an. Die 
Nachrichtenschleife 430 verweist auf den Code, der 
Nachrichten aus einer Nachrichtenwarteschlange, die 
durch das ursprungliche Betriebssystem zur Verfiigung 
gestellt wird, extrahiert Insbesondere fordert, wenn das 
Programm eine Zeichennachricht (Schritt 435, ]A- 
PFAD) empfangt, das Programm die Bildaufbereitung 
der Zeichnenfolge "Hallo" in der Mitte des dargestellten 
Windows an (Schritt 440). Wenn die empfangene Nach- 
richt keine Zeichennachricht ist (Schritt 435, NEIN- 
PFAD), bestimmt das Programm andererseits, ob die 
empfangene Nachricht eine Nachricht zum Beenden ist 
Oder nicht (Schritt 450). Wenn die empfangene Nach- 
richt keine Nachricht zum Beenden ist (Schritt 450. 
NEIN-PFAD), dann fiihrt das Programm eine Schleife 
zuruck zu Schritt 430 aus und wartet auf die nachste 
Nachricht Wenn das Programm eine Nachricht zum 
Beenden empfangt (Schritt 450. JA-PFAD), endet das 
Programm. 

Fig, 5 stellt ein FluBdiagramm der Verfahrensschritte 
fiir die Wechselwirkung zwischen dem Anwendungs- 
programm von Fig. 4 und einem ursprungiichen Be- 
triebssystem dar. Das ursprungliche Betriebssystem ant- 
wortet auf die Registrierung einer neuen Windowklasse 
durch Speichern der KJassendaten fur die neue Daten- 
klasse (Schritt 510). Durch Abspeichem dieser Daten 
kann ein Window oder eine Anzahl von Windows basie- 
rend auf den gespeicherten Klassendaten erzeugt wer- 
den. Als nachstes antwortet das ursprungliche Betriebs- 
system auf den Create- Window-API-Aufruf durch Er- 
zeugung einer Windowstruktur (Schritt 520). Insbeson- 
dere erzeugt das ursprungliche Betriebssystem basie- 
rend auf den von dem Create-Window-API-Aufruf 
ubergebenen Parametern (beispielsweise dem Win- 
dowstil, der Windowuberschrift, der anfanglichen Posi- 
tionierung etc) eine Windowstruktur und gibt dem An- 
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wendungsprogramm eine Handhabe fur die erzeugte 
Windowstruktur zuruck. Nachdem die Windowstruktur 
erzeugt ist, stellt das ursprungliche Betriebssystem als 
Antwort auf den ShowWindow-API-Aufruf (Schritt 
5 530) das Window auf der Bildschirmanzeigeeinrichtung 
des Computersystems dar. Kurz gesagt, schafft das ur- 
sprungliche Betriebssystem dies durch Empfangen der 
Handhabe als Eingabeparameter von dem Anwen- 
dungsprogramm, wobei die Handhabe das Window 

10 kennzeichnet, das das Anwendungsprogramm darstel- 
len wiE Das ursprungliche Betriebssystem empfangt 
ebenfalls einen Eingabebefehl, der anzeigt, ob das Win- 
dow in normalem oder minimiertem Format dargesteilt 
werden soil. Nachdem das ursprungliche Betriebssy- 

15 stem das Window dargesteilt hat, beginnt das Anwen- 
dungsprogramm, Nachrichten von der Nachrichtenwar- 
teschlange iiber die vorher beschriebene Verfahrens- 
schleife (Schritte 410—450 in Fig. 4) einzugeben. Das 
ursprungliche Betriebssystem stellt eine Default-Win- 

20 dowprozedur (Schritt 540 in Fig. 5) zur Verfiigung, die 
alle Nachrichten, die das Anwendungsprogramm selbst 
nicht verarbeitet (d. h., alle Nachrichten mit Ausnahme 
der Nachrichten zum Zeichnen und Beenden) bearbei- 
tet. Wie vorher beschrieben, gibt das Anwendungspro- 

25 gramm, wenn es eine Zeichennachricht empfangt, einen 
Befehl zum Zeichnen von "Hallo" an das ursprungliche 
Betriebssystem. Das ursprungliche Betriebssystem ant- 
wortet auf diesen Befehl durch Aufruf des Bildschirman- 
zeigeeinrichtungstreibers (Schritt 550). Der Bildschirm- 

30 anzeigeeinrichtungstreiber seinerseits gibt den Text an 
die Bildschirmanzeigeeinrichtung ab (Schritt 560). Auf 
die oben beschriebene Weise wechselwirkt das ur- 
sprungliche Betriebssystem mit dem Anwendungspro- 
gramm, so daB ein lokales Window dargesteilt wu*d 

35 Fig. 6 stellt ein FluBdiagramm der Verfahrensschritte 
fur ein Beispiel gemaB einer bevorzugten Ausfuhrungs- 
form der vorliegenden Erfindung dar. Dieses Beispiel 
illustriert, wie eine bevorzugte Ausfiihrungsform fiir ei- 
ne computerferne Interaktion in einer nicht-urspriingli- 

40 chen Umgebung mit einer Ausfiihrung einer Anwen- 
dung in der urspriinglichen Umgebung sorgt. Wie in 
dem FluBdiagramm gesehen werden kann, erlaubt die 
bevorzugte Ausfuhrungsform, daB Systemaufrufe, die 
nicht mit dem Windowmanagement in Beziehung ste- 

45 hen (beispielsweise das Registrieren der Windowklasse) 
direkt an das ursprungliche Betriebssystem gegeben 
werden. Wenn allerdings ein API-Aufruf mit dem Win- 
dowmanagement in Beziehung steht (beispielsweise das 
Erzeugen yon Fenstern, das Darstellen von Fenstern). 

50 fangt das Ubersetzungsverfahren den API-Aufruf ab, 
bevor es den Aufruf zu dem urspriinglichen Betriebssy- 
stem weitergibt (Schritte 610 und 620). In dem FaU, in 
dem API Create Window aufruft, ruft die bevorzugte 
Ausfuhrungsform entweder XGet-Geometry oder 

55 XGetWindow-Attribute auf. um die Dimensionen der 
computerfernen Server-Anzeigeeinrichtung zu bestim- 
men. Wenn die Dimensionen der computerfernen Ser- 
veranzeigeeinrichtung bekannt sind, ruft das Oberset- 
zungsverfahren die Xlib-Funktion XCreate Window, um 

60 ein computerfern dargestelltes Window in einer X-Um- 
gebung zu erzeugen. In ahnlicher Weise stellt das Ober- 
setzungsverfahren, wenn das Anwendungsprogramm 
einen Show Window- API- Auf ruf ausgibt. ein entspre- 
chendes X- Window (Schritt 620) dar, bevor es den 

65 ShowWindow-API-Aufruf an das ursprungliche Be- 
triebssystem leitet Somit stellen die Beispiele in Fig. 6, 
Schritte 610 und 620. die abgefangene Meldung auf ho- 
herer Ebene. die im Zusammenhang mit Schritt 315 in 
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Fig. 3 diskutiert wurde, dar. Analog stellen die Schritte 
630 und 640 in Fig. 6 die abgef angene Meldung auf nied- 
riger Ebene, die in bezug auf Schritt 345 in Fig. 3 disku- 
tiert wurde, dar. Insbesondere fSngt das Obersetzungs- 
verfahren die Aufrufe des Anwendungsprogramms an 5 
den Bildschirmanzeigeeinrichtungstreiber ab (Schritt 
630). Wie oben erlautert, behandelt der Bildschirmtrei- 
ber keine Konstruktionen auf hoher Ebene, wie bei- 
spielsweise Fenster. Als ein Ergebnis mu6 das Oberset- 
zungsverfahren zuerst das entsprechende X- Window 10 
bestiramen, fUr das der Aufruf zum Bildschirmtreiber 
ausgefiihrt wurde. Diese Bestimmung kann durch eine 
Anzahl von Wegen durchgefuhrt werden, Beispielswei- 
se kann diese Bestimmung dadurch durchgefuhrt wer- 
den, daU die Datenstruktur, die die interne Windowzu- 15 
standsinformation f iir alie X- Windows, die derzeitig exi- 
stieren, enthalten. aufrechterhalten und bewerten. In 
diesem Szenario bestimmt das Obersetzungsverfahren 
die Bildschirmkoordinaten, auf die durch den Bild- 
schirmtreiber Bezug genonmien wird. Das Oberset- 20 
zungsverfahren kann dann auf diese Koordinaten quer- 
verweisen, um eine Handhabe fiir die Windowstruktur, 
die diese Koordinaten besitzt, zu erhalten. Auf diese 
Handhabe kann dann seinerseits querverwiesen wer- 
den, um das entsprechende X- Window zu bestimmen. 25 
Nachdem das erwunschte X-Window bestimmt ist, 
ubersetzt das Obersetzungsverfahren die Bildverarbei- 
tungsanfragen in X-Aufrufe und sendet diese Aufrufe 
zum computerfemen X-Server. Auf diese Weise wird 
die computerferne Anzeigeeinrichtung schnell und effi- 30 
zient aktualisiert SchlieBlich gibt das Obersetzungsver- 
fahren optional den Bildschirmanzeigetreiberaufruf an 
den lokalen Bildschirmtreiber, falls erwunscht. Dieser 
Schritt ist nur notwendig, wenn eine lokale Bildaufberei- 
tung erwunscht ist. 35 

Wie in dieser bevorzugten Ausfiihrungsform erklart, 
ermoglicht die vorliegende Erfindung, daB mit Anwen- 
dungsprogrammen, die unter dem ^WINDOWS/ 
NT*-Betriebssystem ausgefiihrt werden, computerfern 
iiber das X-Client/Server-Windowsystem wechselge- 40 
wirkt wird. Eine besonders vorteilhafte Anwendung der 
bevorzugten Ausfiihrungsform betrifft das Gebiet der 
Medizintechnik. Insbesondere liegt eine bevorzugte 
Ausfuhrungsform der vorliegenden Erfindung in der 
Muili- Disclosure Review Station, hergestellt durch Spa- 45 
ceLabs, Incorporated, die einen medizinischen Monitor 
als X-Server verwendet Dieser spezialisierte X-Server 
bereitet die kritischen Daten des Patienten (beispiels- 
weise eine Herzwellenform) auf einem begleitenden 
X-Terminal zum Bild auf. Mit der vorliegenden Erfin- 50 
dung kann der Arzt nicht nur die Herzwellenform eines 
Patienten auf diesem Terminal ansehen, sondern der 
Arzt kann auch auf Anwendungsprogramme, die fiir das 
^WINDOWS/NT" -Betriebssystem geschrieben sind, 
zugreifen. Als Ergebnis wird die Arbeit des Arztes stark 55 
vereinfacht Beispielsweise kann eine Anwendung, wie 
z. B. "MICROSOFT EXCEL" verwendet werden, um ei- 
ne Datenbank der Krankengeschichte des Patienten zu 
erstellen und zu aktualisieren. Somit erlaubt die vorlie- 
gende Erfindung, daB der Arzt die aktualisierte Kran- eo 
kengeschichte des Patienten abruft, wahrend er simul- 
tan die Herzwellenform des Padenten ansieht Da die 
vorliegende Erfindung gleichzeitigen Zugriff zu nio- 
mentanen und vorangegangenen medizinischen Bedin- 
gungen schafft, kann der Arzt schnell und leicht alle 65 
Information erhalten, die notwendig ist. um den Patien- 
ten iiber ein cinzelnes Terminal zu behandeln. Auf diese 
Weise kann der Arzt effizienter arbeiten. 
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Die oben gelieferte, detaillierte Diskussion steUt be- 
vorzugte Ausfiihrungsformen der vorliegenden Erfin- 
dung dar. Diese Diskussion ermoglicht es dem Fach- 
mann, verschiedene Modifikationen dieser Ausfiih- 
rungsform durchzufuhren, die nicht von dem Umfang 
der Erfindung abweichen. Beispielsweise wird, obwohl 
eine bevorzugte Ausfiihrungsform unter Bezugnahme 
auf das "WINDOWS/NT* -Betriebssystem beschrieben 
wurde, der Fachmann erkennen, daB das hierin offen- 
barte erfinderische Konzept nicht auf irgendein speziel- 
les Betriebssystem beschrSnkt ist In ahnlicher Weise 
wird der Fachmann, obwohl die bevorzugte Ausfiih- 
rungsform unter Bezugnahme auf das X-ProtokoU be- 
schrieben wurde, erkennen. daB die hierin offenbarten 
erfinderischen Konzepte nicht auf das ProtokoU irgend- 
eiaer bestimmten, computerfemen grafischen Benutzer- 
oberflache beschrankt sind. DemgemaB beriicksichtigt 
die vorliegende Erfindung alle derartigen Modifikatio- 
nen, die sich auf die angefiigten Anspriiche und Aquiva- 
lente derselben lesen. 

Patentanspriiche 

1. Ein Verfahren, um eine Anwendung als X-Client 
auszufiihren, so daB ermoglicht wird, die Anwen- 
dung mit einem X-Windowsmanager darzustellen, 
wobei das Verfahren die Schritte aufweist: 
Starten einer "WINDOWS/NT "-Sitzung; 
Aufriifen einer Anwendung aus der "WINDOWS/ 
NT"-Sitzung; 

Oberwachen der Ausgabenachrichten, die von der 
Anwendung gesendet werden; 
Bestimmen, wann eine der uberwachten Ausgabe- 
nachrichten ein Befehl emer grafischen Benutzer- 
oberflache ist; und, 

wenn die uberwachte Ausgabenachricht ein Befehl 
einer grafischen Benutzeroberflache ist, Suspendie- 
ren eines 'WINDOWS/NT'-Geratetreibers vom 
Handeln auf den Befehl hin, Handelnlassen eines 
X-Windowsmanager-Programms auf den Befehl 
hin, und Informieren des "WINDOWS/Nr*-Gera- 
tetreibers uber das Ergebnis des Befehls, auf den 
durch das X-Windowsmanager-Programm hin ge- 
handelt worden ist 

2. Das Verfahren nach Anspruch 1, weiter umfas- 
send den Schritt: 

Konvertieren des Befehls von einem 'WINDOWS/ 
NT* -Format in ein Format, das durch einen X-Ser- 
ver interpreuerbar ist, so daB dem X-Server er- 
moglicht wird, auf den Befehl hin zu handeln. 

3. Ein Verfahren zum Bereitstellen eines computer- 
femen Zugriffs auf ein Anwendungsprogramm, das 
unter einem urspriinglichen Betriebssystem ausge- 
ftthrt wird, in welchem das urspriingliche Betriebs- 
system eine Anwendungsschnittstelle zur Verfu- 
gung stellt, um Befehle vom Anwendungspro- 
gramm zu empfangen, und in welchem das Be- 
triebssystem eine ursprungliche grafische Benut- 
zeroberflache zur Verfiigung stellt, wobei das Ver- 
fahren die Schritte aufweist: 
Oberwachen einer Nachricht, die vom Anwen- 
dungsprogramm an die Anwendungsschnittstelle 
ausgegeben wird; 

Abfangen der iiberwachten Nachricht, wenn die 
Nachricht eine Operation ist, die die urspriingliche 
grafische Benutzeroberflache beeinfluBt; und 
Umleiten der abgefangenen Nachricht auf einen 
nicht-urspriinglichen grafischen BenutzeroberflS- 
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chenmanager, so dafi dem nicht-urspriinglichen 
grafischen Benutzeroberfiachenmanager ermog- 
licht wird, die Operation der uberwachten Nach- 
richt durchzufuhren. 

4. Das Verfahren nach Anspruch 3, weiter umfas- 5 
send den Schritt: 

Informieren des ursprunglichen Betriebssystems 
iiber die Ergebnisse der abgefangenen NachrichL 

5. Ein Verfahren 2um Bereitstellen einer computer- 
fernen Anzeige und Interaktion mit einem Anwen- 10 
dungsprogramm, das auf einer lokalen Maschine 
ausgefuhrt wird, wobei die lokale Maschine die An- 
wendung in einer Umgebung elnes ursprunglichen 
Betriebssystems ausfuhrt, in welchem das ur- 
sprungliche Betriebssystem eine !okale Anwen- 15 
dungsschnittstelle, um Befehle vom Anwendungs- 
programni zu empfangen, und eine lokale grafische 
Benutzeroberflache zur Verfiigung steDt, wobei das 
Verfahren die Schritte aufweist: 

Erkennen eines Befehls, der vom Anwendungspro- 20 
gramm an die Anwendungsschnittstelle ausgege- 
ben wird; und 

Konvertieren der erkannten Nachricht von einem 
Format fur die lokale grafische Benutzeroberflache 
in ein Format fiir eine computerferne grafische Be- 25 
nutzeroberfiache, so daB die erkannte Nachricht 
durch eine computerferne grafische Benutzerober- 
flache interpretiert werden kann. 

6. Ein Verfahren zum Bereitstellen einer computer- 
femen Benutzerinteraktion mit einem Anwen- 30 
dungsprogramm, das in seiner ursprunglichen Um- 
gebung auf einer Hauptmaschine ausgefuhrt wird, 
wobei die ursprungiiche Umgebung eine lokale 
grafische Benutzeroberflache zur Verfiigung stellt, 
die eine lokale Benutzerinteraktion mit dem An- 35 
wendungsprogramm erlaubt, wobei das Verfahren 
die Schritte aufweist: 

Bestimmen, wann das Anwendungsprogramm ei- 
nen Befehl an die lokale grafische Benutzeroberfla- 
che gesendet hat; 40 
Suspendieren der Fahigkeit der ursprunglichen 
Umgebung, den bestimmten Befehl zu verarbeiten; 
und 

Konvertieren des bestimmten Bef ehls in ein Proto- 
koll, das von einer computerfernen grafischen 45 
Oberflache erkennbar ist. 

7. Eine Vorrichtung, die es erlaubt, ein Anwen- 
dungsprogramm wie einen computerfernen 
X-Clienten zu behandeln, wahrend das Anwen- 
dungsprogramm in einer Nicht-Unix- Umgebung 50 
ablauftj wobei die Vorrichtung aufweist: 

eine Oberwachungseinrichtung, die bestimmt, 
wann das Anwendungsprogramm einen Befehl an 
eine lokale grafische Benutzeroberflache gesendet 
hat, wobei die Jokale grafische Benutzeroberflache 55 
durch die Nicht-Unix-Umgebung zur Verfiigung 
gestellt wird; 

eine Deaktivierungseinrichtung, die die Fahigkeit 
der Nicht-Unix-Umgebung, den bestimmten Befehl 
zu verarbeiten, deaktiviert; und eo 
eine Modifiziereinrichtung, die den besthnmten Be- 
fehl in ein Protokoll, das von einer computerfernen 
grafischen Oberflache erkennbar ist, konvertiert 

8. Ein Verfahren, das es erlaubt, eine Windows- 
oder "WINDOWS/NT"-Anwendung, zusatzlich zu 65 
ihrer Ausfuhrung als X-Client, in ihrer ursprungli- 
chen Umgebung auszufiihren, so daB ermoglicht 
wird, die Anwendung auf einem computerfernen 
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X-Terminal darzustellen, wobei das Verfahren die 
Schritte aufweist: 

computerfernes Starten einer Windows- oder 
"WINDOWS/NT'-Anwendung; 
Oberwachen von System-Aufrufen und Anzeige- 
einrichtungstreiber-Aufrufen, die von der Win- 
dows- Oder der *WINDOWS/NT" -Anwendung 
ausgefuhrt werden; 

Bestimmen, wann einer der uberwachten System- 
Aufrufe ein mit einer grafischen Benutzeroberfla- 
che zusammenhangender Befehl ist; 
Bestinmien, wann eine Bildschirm-Bildaufbereitung 
filr ein Fenster, das der Windows- oder der *WIN- 
DOWS/NT"-Anwendimg zugeordnet ist, bestimmt 
ist; und, 

jedesmal wenn uberwachte System-Aufrufe Befeh- 
le einer grafischen Benutzeroberflache sind und je- 
desmal wenn eine Anzeigeneinrichtungstreiber- 
Bildaufbereitung auf ein Fenster, das dem Win- 
dows- Oder dem ''WINDOWS/NT'-Anwendungs- 
programm zugeordnet ist, abzielt, Ausfiihren ge- 
eigneter X-System-Aufrufe, um die beabsichtigte 
Wirkung auf dem computerfernen X-Terminal zu 
erzielen. und dann Zulassen, dafi ein Betriebssy- 
stem der ursprunglichen Umgebung den Aufruf 
verarbeitet 

9. Ein Verfahren zur Laufzeitubersetzung von ei- 
nem ersten grafischen Betriebssystem in ein zwei- 
tes grafisches Betriebssystem, in welchem das erste 
grafische Betriebssystem keine computerferne 
Darstellung von Anwendungsprogrammen vor- 
sieht und in welchem das zweite grafische Betriebs- 
system eine computerferne Darstellung von An- 
wendungsprogrammen vorsieht, wobei das Verfah- 
ren die Schritte aufweist: 

Oberwachen von System-Aufrufen und Anzeigein- 
richtungstreiber-Aufrufen, die von einem Anwen- 
dungsprogramm, das unter dem ersten grafischen 
Betriebssystem ausgefuhrt wird, durchgefiihrt wer- 
den; 

Bestimmen. wann einer der uberwachten System- 
Aufrufe ein mit einer grafischen Benutzeroberfla- 
che zusammenhangender Befehl ist; 
Bestimmen, wann eine Bildschirm-Bildaufbereitung 
auf ein Fenster abzielt, das dem Anwendungspro- 
gramm, das unter dem ersten grafischen Betriebs- 
system ausgefuhrt wird, zugeordnet ist, und, 
jedesmal wenn uberwachte System-Aufrufe Befeh- 
le einer grafischen Benutzeroberflache sind und je- 
desmal wenn eine Anzeigeneinrichtungstreiber- 
Bildaufbereitung auf ein Fenster abzielt, das dem 
Anwendungsprogramm, das unter dem ersten gra- 
fischen Betriebssystem ausgefuhrt wird, zugeord- 
net ist, Ausfiihren geeigneter Befehle in dem zwei- 
ten grafischen Betriebssystem, um die beabsichtig- 
te Wirkung auf einer computerfernen Anzeigeein- 
richtung, die vom zweiten grafischen Betriebssy- 
stem gesteuert wird, zu erzielen, und dann Zulas- 
sen, daB das erste grafische Betriebssystem den 
Aufruf verarbeitet. 

10. Ein Verfahren zum Obersetzen von Befehlen 
eines Anwendungsprogramms aus einem ersten 
grafischen Betriebssystem in ein zweites grafisches 
Betriebssystem, wobei das Anwendungsprogramm 
in der ersten grafischen Umgebung ausgefuhrt 
wird, in welchem das erste grafische Betriebssy- 
stem keine computerferne Darstellung des Anwen- 
dungsprogramms vorsieht und in welchem das 
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zweite grafische Betriebssystem eine computerfer- 
ne Darstellung des Anwendungsprogramms vor- 
sieht, wobei das Verfahren die Schritte aufweist: 
Oberwachen von Geratetreiber-Aufrufen, die 
durch das Anwendungsprogramm ausgefuhrt war- 5 
den; 

Bestimmen, wann einer der iiberwachten Gerate- 
treiber-Aufrufe auf ein Fenster, das dem Anwen- 
dungsprogramm zugeordnet ist, abzielt, und, 
jedesmal wenn einer der iiberwachten Geratetrei- 10 
ber-Aufrufe auf ein Fenster, das dem Anwendungs- 
programm zugeordnet ist, abzielt, Ausgeben geeig- 
neter Befehle in dem zweiten grafischen Betriebs- 
system. um die beabsichtigte Wirkung auf einer 
com puterf ernen Anzeigeeinrich tung, die vom zwei- 1 5 
ten grafischen Betriebssystem gesteuert wird, zu 
erzielen. 
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